Override coalesce with a Doltgres-specific implementation#2850
Conversation
|
|
SummaryThis run focused on database expression behavior around null-fallback logic in reads and writes, including normal flows, type-edge cases, and retry/atomicity behavior after conversion errors. Overall health is mostly stable, with core fallback semantics and consistency checks behaving as expected across varied query shapes. Safe to merge — the only regression tied to this PR is a minor issue in a narrow no-op update typing path, while the broader behavior exercised here remained stable. A separate medium-severity update typing failure was also observed but appears pre-existing, so it is a caveat to track rather than a blocker for this merge. Tests run by ItoAdditional Findings DetailsThese findings are unrelated to the current changes but were observed during testing. 🟡 UPDATE on date column remains a no-op
Evidence PackageTip Reply with @itoqa to send us feedback on this test run. |
|
…with DoltgresTypes
4eecb70 to
4372ed8
Compare
Commit: SummaryThis run exercised SQL COALESCE behavior across normal update flows, parameterized execution paths, mixed-type resolution, and failure handling, including checks for statement atomicity and deterministic error behavior. Core no-op update and fallback paths looked stable, but compatibility handling for mixed concrete types showed regressions in the new logic. Not safe to merge yet — the PR introduces a high-severity correctness issue in changed COALESCE type-handling paths where incompatible inputs can be accepted and return values instead of being rejected. A separate medium-severity mixed-integer conversion failure in the same area further raises confidence that type resolution and conversion logic still needs fixes before merge. Tests run by ItoTip Reply with @itoqa to send us feedback on this test run. |


The
coalesceimplementation in GMS does not properly handle Doltgres types. This PR adds a small Doltgres-specific implementation that properly handles Doltgres types.Fixes: #2332